Development Case		 The development-case description describes the development process that you have chosen to follow in your project.
Topics

Explanation To top of page

Expressed in terms of business engineering, the software development process is a business process, whereas the Rational Unified Process product is a generic business process for object-oriented software engineering. A development case is a static configuration of the Rational Unified Process product; that is, it's a business process for software engineering tailored to a specific project, product, and organization. The development case focuses on what to do and how to do it.

A development case shows how the generic Rational Unified Process applies to the context of your organization. This means that you modify the process and adapt the terminology.

A development case also provides an overview of the process to be followed, something understood by everyone on the project. For details, the development case should refer to the Rational Unified Process and other guidelines or styleguides.

Process configuration is the activity of deriving a development case from the more general process presented in the Rational Unified Process. For a sample of a development case, see Example: Development Case.

The process engineer is responsible for configuring the process, deciding how the development process will look, "installing" the development case in the development organization (team, project or company), and teaching the developers how to use it.

Keep in mind that introducing a new development process, such as the Rational Unified Process, into an organization is always a risk. You must continually weigh the advantages of a new technique against the cost of introducing the change. Consider introducing a change from both a managerial and a technical perspective.

Once a development case is set up by the process engineer, the project manager instantiates and executes it for the given project. This is often called process enactment.

As the process unfolds, lessons are learned during the process itself, which are used by the process engineer as feedback to improve the process.

Variable Elements in Software Engineering Processes To top of page

This section reviews the constituents of a process that are likely to be modified, customized, added or suppressed in a given development case.

  • Core process workflows
    A software project would rarely skip one of the core process workflows, such as Analysis & Design, Implementation, and so on, completely. In exceptional cases, some core process workflows, such as Requirements or Deployment, may have been executed by other organizations. However, it's more likely that specific workflows within or across core process workflows would be modified.  
  • Artifacts
    Projects are far more likely to differ by the artifacts that they have to produce, update, and deliver. At one extremity of the range, imagine a totally paperless project that electronically maintains only a small number of artifacts, is supported by tools such as spreadsheets, design tools, programming tools, and testing tools, and only delivers software and documentation electronically on disk, CD or over the World-Wide Web. At the other extreme, there are projects that must produce and maintain a much larger set of printed documents for contractual, regulatory or organizational reasons. In some cases, complete models can be omitted.
  • Activities
    Activities are likely to vary for at least two reasons. Activities that use artifacts as input and produce, or update, artifacts as output are affected by the modification of these artifacts; in particular, if some artifact, or some element of information in an artifact, is no longer necessary, the corresponding steps maybe suppressed or significantly modified. Activities are also modified to introduce specific techniques, methods, and tools that pertain to the specific application domain or development expertise, such as design steps, programming languages, automatic code generation tools, measurement techniques, and so on.

At a more detailed level, other elements of the process can be modified, added or suppressed:

  • Steps in activities.
  • Guidelines and guidance for activities.
  • Notations, such as using subsets of the UML or using stereotypes to address some specific need for some, or all, models.
  • Checkpoints for inspections and reviews.
  • Workers.
  • Tool support to automate some activities.
  • Terminology changes, for instance to adapt the process to the organizational context.

In summary, the process engineer must make a wide range of decisions to create a well-adjusted development case out of the Rational Unified Process. A development case may have to be adjusted to take advantage of certain well-established company practices and standards, such as documents, terminology, and so on.

Difficult Configurations To top of page

Certain configuration forms are difficult to implement and must be considered very carefully. For example:

  • Change in process architecture
    Wide-ranging repackaging of the activities in another set of core process workflows to match an existing process or organization may lead to a lot of effort for very little gain. Often, it's more practical to simply establish a mapping to assess whether all aspects are covered by the Rational Unified Process. Remember that the core process workflows are not phases sequentially executedùthey are containers for activities, and are executed again and again at each iteration, often concurrently within one iteration.
  • Changes in terminology
    Although substituting one word for another may sound like a trivial exercise in word processing, such changes must be considered very carefully. In the domain of software engineering, organizations often use the same word with slightly different meanings, or different words that mean the same thing. Making isolated changes in the Rational Unified Process may lead to a process that is very difficult to understand. One solution is to create a "translation table" for the terminology that translates between the Rational Unified Process terminology and the organization's terminology.

Examples of dangerous words are system, phase, role, activity, model, and document.

If the process results are captured in a language other than English, the terminology issues are more complex where you must translate the descriptions of artifacts, documents, reports, and possibly other parts of the Rational Unified Process to this other language.

Delegating Process Responsibility To top of page

The development case does not have to capture the entire process. In reality, a lot of responsibility, and decisions about the process, and the artifacts in particular, are delegated to members of the software development project. For example, if there is an experienced, good project manager, you may leave it to this individual to decide on what plans to produce and how to produce them. In the same way, many project managers aren't concerned about how each team member designs his or her part of the system, as long as they deliver the expected functionality on time and within a reasonable level of quality.

One reason for having a process description at all is so several people can share information. If this is not the case, then the cost of maintaining the process description may be too high. Therefore, you may decide not to have, or maintain, the process description for one or several workflows. This doesn't mean that you don't put effort into that particular workflow, nor does it mean that you don't think it's important. For example, you may employ an excellent test manager, provide all possible support, but leave it to that test manager to decide how to work and what artifacts to produce.

Representing a Development Case Online To top of page

A development case can be represented in several different ways:

One or Several Web pages

It's easiest to represent it as a Microsoft Word document, however, we recommend you represent the development case as one or several Web pages with hyperlinks to the Rational Unified Process when needed. See the Tool Mentor: Adding External Links to Rational Unified Process for more details on how to add hyperlinks. If you have developed an organization-specific process product based on the Rational Unified Process, the development case will have hyperlinks to it. See Concepts: Process Configuration for more details.

We recommend that you integrate the development case in your project Web site, if you have one. See Tool Mentor: Creating Your Project Web.

A Web Site with Navigational Tools

You could build the development case as a Web site with navigational tools, like the Rational Unified Process online. That is, you can use Web development tools such as Microsoft« FrontPage« and the Rational Unified Process tools. For specific information about how to develop Web pages, see the Guideline: Rational Unified Process Styleguide. Also see Rational Unified Process Development Tool Mentors for those tool mentors that describe how to use FrontPage and the Rational Unified Process tools. 

We recommend that you integrate the development case in your project Web site, if you have one. See Tool Mentor: Creating Your Project Web.

Integrated with Rational Unified Process Online

You can also integrate the development case in the Rational Unified Process online. This can be done by modifying the treebrowser and adding a new entry to both the Development Case and the project-specific guidelines. See Tool Mentor: Modifying the Treebrowser for details. However, there is a clear drawback to this approach, since you make the Rational Unified Process specific to the project when you add project-specific information to the Rational Unified Process. We only recommend this approach if the Rational Unified Process online will be used in a single project.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process